Client -SeiyerComputm^^ 

Field of the In vention : ; : 

This invention relates to a method for perfonning a transaction between 
computer systems, particularty #ent-server transaction, and more particularly to the 
execution of service requests, 

10 Background of the Invention 

In modem large computing systemsV a common topology has three tiers: (i) a 
presentation tier characterized by multiple client workstations focusing on user 
interactions, (ii) a business, tier characterized yvby multiple servers executing 
15 application/business logic, m\d (iii) a data tier ch^terized by multiple databases 
working on data storage and organization. A Local or Wide Area Network (LANAVAN) 
interconnects the three tier elements. 

Such computing systems find application in many and varied fields, ranging 
20, fi-om university research and teaching fecilities to business applications. In fact, almost 
every business will utilise such a system to transact its functions and serve its clients. For 
example, a system may be used to control inventoiy, for word processing and accounts 
purposes, and for servicing client's enquiries. Many businesses have very large client 
bases and may provide an extensive inventory of goods and services. One illustrative 
25 example is a telecommunications service provider (Telco) that serves a countryvwde client 
base. The Telco's subscribers .thus can number in the itnillions, and each customer will 
expect a near immediate respoiise from a Customer Service Representative (CSR) to any 
inquiry, which can range fr6m billing information, a request for a new service, or the 
placing of orders for a product. 

•30 ' ■ - - " " . ■'. ' " ■ ■" , 

Sunilar examples are seen in Utilities, iiisuraiice companies, banks, hospitals, 
law firms, accountancy firms^stock exchanges, universities and Government agencies, to 
namebutafew. 
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Any client-server system requires a software architecture. One such known 
architecture is the Common Object Request Broker Architecture (CORBA) Standard 
devised by the Object Management Group. A description of the CORBA Standard can be 
found at the OMG website: http://www.omg.org/corbra. 

It is common for a software architecture to be implemented by object oriented 
programs. Objects exist only in an abstract world; making it necessary to give them a 
'reality' - in the sense of packets of bytes - when they are passed between distributed 
processes of a computing system. A client-server interaction can be between two 
10 machines (e.g. client machine: and server machine; of server machine and database) or - 
between two processes residing bti the same machine. A concomitant of CORBA is ttie 
Interface Definition Language (DDL) that performs the translation of instances of objects 
to physical data packets, and vice versa. 

15 In CORBA version 2.0/ distributed objects (coiistituted by attri^ 

behaviour states) have locations tiiaf are unknown to the clients of those objects (i.e. other 
processes). The chents work witii a proxy object (i.e: an imposter) that provides interface 
compatibility with the remote object. The remote object maintains the state information 
from which the proxy obtains, its state information. In other words, the objects of one 

20 process contain a pointer to the relevant object of another process. It is only the pointer 
that is passed between processes: This is known as flie; - pass by reference' paradigm. 

CORBA version 3vO; 0n the other hand, contemplates objects 'passed by value'. 
This means that the actual object is passed between processes. For computing systems 

25 implementing a Telco client service function (for example), a CORBA software 
architecture requires thatfor each proxy object existing on a client, the actual object must 
exist on the server for the lifetiBQe of the proxy object; Also, any single object can have 
hundreds of attributes and relationships with similar numbers of other objects, and these 
also will be passed across the network. These requirements can impose extreme demand 

30 on memory space and network bandwidth, which can degrade performance (e.g. response 
time) of the system application(s). 

It is an object of the invention to avoid, or at least ameliorate the foregoing 
problems. It is a further preferred object to provide a client-sever transaction that is 
35 highly scalable in a distributed'object-oriented application. 
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Summaiy of the Invention ; ^ 

In a first aspect the; iriVention provides a method for performing, a cl^ 
transaction, comprising the steps of: . 

(a) instantiating: a transactional object on a client directly corresponding to 
a service request; 

(b) instantiating one or more business-related objects on said client; 

(c) said clieiit associating said business objects with a said seivice object; 

(d) transporting said service and associated business objects to a server; and 

(e) said server executing said service object. 

In a fiuther aspect the invention provides a iriethod for perfor^^ 
transaction, comprising the steps of: 

(a) defining a series of transactional objects on a client, each object directly 
corresponding to a service request; 

(b) defining a series of business-related objects on said server; 

(c) in response to a service request, instantiating a service object on said 
client fi-om among said series of service objects; : 

(d) iiistantiating one more business objects on said client; 

(e) associating said one or more business objects with said service object on 
said client; 

(f) transportinjg ^aid service and associated business objects to a server; 

(g) executing said iservice object by said server; 

(h) modifying said business objects or instantiating new business objects by ; 
said server in response to said execution; and 

(i) returning saidjservice object and said modified or new business objects 
to said client 

In a fiirther aspect the invention provides a method for performing a client-server 
transaction, comprising the steps of : 

(a) instantiating a transactional object on the client that directly cpiresponds 
to a service request; 

(b) transporting said object to a server; and 

(c) executing said service on said server. 



ovn/oo 



'-■'.r^:':-- ■ ' .--4- ■:.v.^:;:: ' 



5'i E 
6 =r 

14, 



In a further aspedt the^^m^ 

(a) a client process including: 

(i) an application layer in vs^ch exists a series of transactional 
5 objects directly corresponding to a service request, and a series of 

business^relattsd objects, and wherein, in response to a service request, 
one of said service objects is instantiated and associated with one or 
more instantiated said business objects; and 

(ii) a midiUev^are layer in which said service and associated business 
10 objects are converted into a binary stream; and 

(b) a server process including: 

(i) a middleware layer, receiving said binary stream and recovering 
said service and business objects;; and 

(li) an application layer executing said recovered service object 



I d In a yet further aspect the invention provides a client-server computing system, 

comprising: 

(a) a plurality ofclient computers each Mving processor means implementing 
==S an application layer, and means implementing a middleware layer linked with a 

20 respective application layer; 

(b) a plurality of server computers, each haiying processor means implementing 
an application layef^^and means implementing a respective middleware layer; 
and _ 

(c) a communications lirik interconnecting said client 
25 machines such that service requests and corresponding replies can be sent 

between a client machine Md a server machuies; and 

wherein, in response to a service request on a client machine, said client 
application layer instantiates a transactional object corresponding to said service request 
and instantiates one or more business-related objects, associates said service object with 
30 said one or more business objects, and passes said associated object to said client 
middleware layer, said client middleware layer passing . a binary form of said associated 
objects to said server middleware layer via said communications link, and further wherein, 
said server middleware layer reinstantiates said associated objects and passes them to said 
server application layer for said service object to be executed, the result of said execution 
35 causing said business objects to be modified or reinstaatiated, and said service object 



associated with said modified or new business objects being returned to said client 
application layer via said server rniddleware layer aiid said client middleware layer. 

The invention further offers an object oriented programing construct of a; 
transactional object directly corresponding to a service request associated with one or 
more business-related objects: : 

The associated business objects can be filtered to pass only selected attributes or 
behaviours. Further, translation logic can be defined for translating executing business 
objects to a database form. The database is accessed by the database fonn of the objects 
to conduct an enquiry. The service and associated business objects are converted to a 
binary stream on the client and recovered on the server. The client and server can include 
storage means, storing the series of service and busihess object definitions, and, on the 
server, database translational logic. 

In a fiirther aspect the invention provides a method for perforining a computer 
process, comprising the steps Of: 

(a) instantiating a transactional object directly corresponding to a service 

request; 

(b) instantiating one or more business-related objects; 

(c) associating said business objects with a said service object; 

(d) transporting said service and ass;ociated business objects to an^ 
computer system. 

In a further aspect the invention provides a computer-readable medium having a 
plurality of sequences of instructions stored thereon including sequences of instructions 
which, when executed by one or more processors, cause said one or more processors to 
perform the steps of : 

(a) iiistantiating at transactional object on a chent directly corresponding to 
a service request; 

(b) inistantiating one or more business-related objects on said client; 

(c) said client associating said business objects with a said service object; 

(d) transporting said service and associated business objects to a server; and - 

(e) said server executing said service object. 



Brief Description of the Drjai^ings Mi 

Embodiments of the':invention wilT^^i^^ witli 'reference tb -the 

accompanying drawings, in which: 

Fig. 1 shows the topology of a distributedvcomputing system; 
Fig. 2 is a generaHsedarchitecture diagram; 

Fig. 3 shows the chent-server software architecture of Fig.2 in more detail; 
Fig. 4 shows an object model for a Business Object; 
Fig. 5 is a flow diagrarti showing build-time processes; 
Fig. 6 is an object model for Filter Objects; > 

Fig. 7 is an object model for a Translation (I)B> : 

Fig. 8 is a flow diagram showing events that occur on a client when a service is 
created and executed; 

Fig. 9 is a flow diagram showing events that occur on a server when a service is 
created and executed; and 

Fig. 10 is a flow diagram showing events that occur on a client when a response 
is received from a server. 

Description of Preferred Embodiments and B^i ]^^ 

Representative Application Environment 

Fig. 1 is a representative topology of a three tier computing system 10 upon 
which the invention can be implemented. The presentation (or client/user) tier is 
represented by a number (l,.:n) of workstations 20, that can be appropriate computing 
terminals, for example personal computers. The business tier is represented by a number 
(l...p) of servers 30, that can be dedicated mini or mainframe computers. The data tier 
is represented by a number :(l...m) of databases 40, which can include dynamically 
managed magnetic or optical storage media. 

The computing system 10 is of an 'open' design, providing communication links 
60,62,64, via external networks 70,72,74 to likenlevices 22,32,42 and remote telephone 
terminals 24, 26. 
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The workstations 20; servers 30, and databases 40 are interconnected by a Local 
or Wide Area Network (LAN. or WAN) 50. The LANAVAN 50 carries information 
passing between each of the three basic elements diefscribed It will be appreciated that the 
tofiology shown in Fig. 1 is representative onlyv and that any other convenient form of 
5 network could be implemented; siich that the objective of information passing between the 
workstations 20, servers 30/aiid databases 40 is achieved. 

For the purposes of a non-limiting illustration^ consider the system 10 of Fig. 1 
being used by a Telco operating across many States of the United States, Such a Telco 

10 will typically support local, regional, interstate^d: international voice and data calls, as 
well as cellular mobile voice Md data traffic. Customers of the Telco can choose from a 
wide range of goods and services including, for example, the installation of second 
. phone/fax/Intemet lines, call forwarding, and messaging. They also will expect to be able 
to make enquiries of CSRs statipried at the workstations 20 concerning billing and service 

15 faults. It is not unreasonable; to expect a modemrday Telco to have at least 1 million 
customers, typically requiring at least 500 CSRs. ^A Telco system infrastructure of this 
sizecanexpecttohandle about 15,000 business traiisactions per ho For each business 
transaction there may be 6 CSR machine transactions required, and each individual 
machine transaction can involve up to 20 database transactiohs (i.e. I/Os). 

20 . • ' ^ \ ■ . ' ' 

To give a better example of the size of computing hardware required to achieve 
such performance, it is considered that the CSR workstations 20 should be Pentium™ 
personal computers running ;the Windo\\^ NT™ opeiating system, the servers 30 can be 
one or more IBM UNIX™-based 12.way RS6000^ S-70 machines, and the databases 

25 would require a capacity of abbut 40 Gbytes, naaoE^ed by an Oracle ™ or IBM DB-2™ 
system. There would, of cburse, be other operational LANAVAN servers required to 
handle data communicationSjVas would be readily understood by a person skilled in the art. 

In business systems such as a Telco, custoiners call CSRs and request goods or 
30 services in everyday language, such as a request for *call waiting' to be activated on a 
domestic telephone line. Indeed, the CSR also operates at this level and is presented with 
information (as a GUI) on the display of the workstation relating to such goods and 
services. The computing system 10 then acts on customers ordered goods or services or 
inquiries. 
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Overview ; * ' : - • 

Fig. 2 shows a reducefd rejM'esentation of the;client-server system of Fig. 1 , in the 
form of a single 'client prdGess\ 'server process'; and database. As mentioned above, the 
5 processes can reside on a res^iective client workstation 20 and server machine 30, or on a 
single server machine 30. Another configuration: could be the browser of a personal 
computer acting as the client arid a web application server acting as the server. That same 
web application server could act, at the same time, as a client of a server mainframe 
machine. 

. > . ' ' ' . v-" ■ ■ ' • . 

On the client, the presentation (UI) layer i 00 presents a user with a graphical 

user interface. In the Telcd illustration mentioned above; a CSR could implement 

business-level transactions via the UI, such as Tind Ciistomer', which seeks to extract a 

customer's details. The application (process) layer 102 is where a CSR's inquiries or 

15 orders are translated into * service requests'. The middleware (SRB) layer 104 deals with 

the framing and dispatching of service requests as bit streams. 

On the server, a similarj but not identical middleware (SRB) layer 106 receives 
bit streams and recreates service requests therefrom: The server SRB 106 communicates 
20 with the server application (prdcess) layer 108 where the recreated service requests are 
executed. The application layer 108 has communicatibti with a dateibase 40 to persist or 
retrieve data stored therein relating to any service requests. 

In response to a service request on the client, the methodology at run-time 

25 involves: 



1 . Instantiation of one or more Business Obj ects (BOs) on the client 

2. Populating the BO with any needed attributes 

3. Instantiating a Service Object (SO) on the client 

30 4. Populating (i.e. associating) the SO with one or more BO(s) 

5. Requesting the SO to be executed 

6. Passing the populated SO to flie server as a binary stream 

7. Reinstantiating the SO and associated BO(s) on the server 

8. Executing the service on the server : 

35 9. Popdating the SO with the results ofthe executed service 



10. Passing the result so ba^^ 

11. Updating the^BO, attributes 

What is to be rioted is that execution of the service occurs only on the server. 
5 Also, no record of the Business or Service Object is kept on either the client or the server 
- the BOs an SOs exist only for the duration of the service execution. 

The idea of a Serivce Object - which equates to the action required to be 
performed on the (one or more) Business Objects f- is key. Compared with the prior art, 
10 the Service Objects represent a further class of object. The thrust of the present invention 
is mainly on the action to be performed, captured by the SOs that execute on the server. 
The number of calls that must be made between client and server is reduced, and the need 
for copies of objects to be stored on both client and server is obviated 
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15 Specific Implementation 

A fuller description of the invention will now be given with reference to Figs. 3 



20 Fig. 3 is a software architecture, similar to Fig. 2, but showing the respective 

layers in greater detail. The cUent has the eldrients of a User Interface 100, an 
application layer 102, and a Service Request Broker 104, The server 30 has a similar (but 
not identical) SRB layer 106, and an application layer 108. The application layer 108 
links to a Common Data Services system 109, controlling access to an exteriial database 

25 40 (or an external server system 32). 

A Controller and Director subsystem 1 10 resides within the UI 100, and passes 
and receives data to a service subsystem 112 that includes a linked 'execute' operation 
,114. Service Objects to be ekecuted are passed to a Mapper subsystem 116, that can be 
30 constituted by code written in C-H-, Java, or any other suitable programing language. The 
Mapper subsystem 1 16 is linked to a Transaction subsystem 118, which has a dispatching 
functioa The Transaction siibsystem maps SOs to destination servers. A 
Communications subsystem 120 packages objects into (or from) binary data streams. 
This can be achieved by middleware such as thb CICS- Encina, or AS 400 Queue 
35 products of Intemational Business Machines Corporation. Other possibilities include MQ, 
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HTTP, TCP/IP sockets,^ CORBA, and Java Rm:^:^ two-^^ network link 130 passes 
binary data between the client;and the server (i.e. request and reply). 

On the server, binary data is handled by a transaction Controller 140. In turn, 
5 the Transaction Controller 140 passes reinstantiated objects to a matching Mapper 
subsystem 142. The application layer 108 provides an execute function 144 on each 50 
and the associated BOs. 

The SOs and BOs that are utilized by the client and server are defined in a 
10 'Build-time' (as will be described). 

" - . ■ ' - ■ ' ■ '/'::'-:( . ' . \ . . 

Business Objects 

Taking the Telco example, a Business Object Teliates to the 'business world' 
15 functionality performed by the computing system 10 - in this embodiment a customer care 
and billing service. Specific examples of BOs are "Cm^ "Account" and 

"Statement". BOs thus can b^ lliought of as the building blocks or actors of the Telco 
customer care and billing business. They are 'data', or things of interest in a business 
sense. 

Service Objects 

A Service Object capttires a transactional property of the one or more BOs with 
which it is associated In oliier words, a SO acts upon one or more BOs to catpure their 

25 intended interaction. SOs perform actions against BOs. They usually represent a 
business transaction An example of a Service Object would be 'Find Customer'. A 
FindCustomer SO could result in the interaction vrith a 'Customer' BO and an 'Address' 
BO. On the other hand, the service request could be to fi^ ; 
vwth a given letter, meaning that there is only an interaction with the 'Customer' BO. 

30 " • .■ ; 

Fig. 4 shows an object diagram for the FindCustomer SO 145, which has the 
attribute 'SearchPattem'. The SO 145 has a 1-to-n association vwth the BO 'Customer' 
146. By 'association', is meant that the BO constitutes the parameter or arguments for 
the SO. The 'Customer' Object 146 has the attributes 'Name', 'Type', and 'Subtype': It, 

35 in turn, has a 1-to-n association with a BO 'Address' 147r This association is navicable in 
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both directions. The ^Address? Object 147 has the attributes 'CityNatne' and 'Location'. 
Additionally, * Address' has inheritances from the^sub&classes *BusinessAddessM48 and 
'ResidentialAddress' 149, they have the respective attributes of TaxNumber' and 
'MobileNumber\ and 'DoorNuniber' and 'StreetName'. 

Build-Time ■ : ■ 

Fig. 5 shows the steps performed during 'buiid-time\ by which three '"schemas" 
are utilized. These are the deifinition of: (i) Business and Service Objects (existing in the 
client and server application layers 102, 108), (ii) mapper filters (existing in the mapper 
subsytem 116), and (iii) database access ^dbjects-tcnrelational database' translation 
(existing in the Common Data Services system 109). These schema definitions are 
achieved by use of the Object Definition I^guage(ODL), 

The ODL performs the interface between tiie object world and the physical layer 
world. It captures the complete state descriptions of objects and also their partial states 
(i.e. through the use of the Filters), and also object translations (i.e. Translators). The 
schema language supports complex inheritance patterns and relationships of BOs and SOs. 
The ODL enables all objects to be represented externally in a common language. This 
enables applications vwitten in different languages to use the same objects. 

The first two schema definitions are relevant to, both client and server, however, 
the third schema applies to oiily the server. 

(i) Object Schemas 

The schema definition for the 'Customer' Object 1 46 hierarchy shown in Fig 4, 
step 150, is: 

object . Customer { . 

String Name, Type, . Subtype ; 
many_relatibri Address [Address]; 
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The relationship with the Address Object- 147 is specified by the many_relation 
syntax. The "[Address]" is the name of the association. The remaining Objects 147-149 
are defined by the following syntax: 

5 object Address! ^ 

String CityName, Location; 

■I' ' ' ■ . ■. " " 

object BusinessAddress inherits. Address { . 
10 String FaxNumber, POBoxl^iumber; 

object ResidentialAddress inherits Address { 
String DoorNumber, StreetName; 

15 }; ' ■ ; 

These syntactical definitions are applied to a suitable schema compiler in step 
152, to establish the Business Objects definitions: The compiler converts the syntax into 
a high level code, such as C++ or Java. 

H ■ ■ ■■■■ '''■^■■y---:i^ ..- 

i y Next, in step 1 54, the Service Object schemas are defined. The specific 

''''Z embodiment is *FindCustomer' 145. 
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object FindCustomer{ . 
25 String . SearchPattern; 

many_relation Customer [resultSetj; = 

.'■-■}; ' ' ' '-.^y-^ ■ - ,' ' . 

The syntax defines the Service Objiect for the business service hsting all 
30 Customers whose names match the given Search Pattern. The syntax could equally be 
written in XML. 

This definition is appUed to the schema conipiler, in step 156, to generate code in 
a high level language such as C++ or Java to estabhsh Seirvice Object definitions. 
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In step 158, the appropriate *business. l6gie^ is defined. This represents the 
behaviour exhibited by eacEBiisiness Object For th^e-Custonier 14, an example of such 
behaviour is the logic to identify all credit accounts of a given customer that are overdue. 
For an Account BO, the busihesis logic might identify all statements attached to an 
5 account. 

Business logic attributes of BOs can impact on the execution of a SO. For 
example, some SOs rely directly on the behaviour of an associated BO: The service of 
identifying over-due credit accounts for a given- customer requires the SO to directly 
10 utilize the Customer BO business logic. A service request can interact with tw^o or more 
BOs. The service, of identifying over-due accounts for a given customer and the 
production of statements for the last three months on each account requires the SO to 
interact with the business logic of the Customer and Account BOs. 

15 (ii) Filter Schemas 



In step 160, Filter Schemas are defined. Fig. 6 shows an object diagram relating 

ll to the above-noted syntax. The CustomerFilter i82 has the atdibutes 'Name', 'Type', 

= - and 'Subtype'. It has association with 'AddressFilter' 182, which has the single attribute 

s 20 'Location'. AddressFilter 182 iriherits the filter objects BiisinessAddressFilter 184 a^^ 

l y ResidentialAddressFilter 186. :BusinessAddressFilter has the attributes 'FaxNumbers' 

't, and 'MobileNumber'. On the other hand, ResidentialAddressFilter 186, has only the 

r^; attribute DooiNumber. 



25 For the Address Object 147,-the AddressFilter Object syntax is as follows; 



filter -AddressFilter filters Address { • 
Location; ■ 

' }; ' V. ^ ■ ^ ' " ' ■ ' 

A Filter refiries an object, meaning that the filter lets only the attributes specified 
in the definition to pass through to an external stream (which could be a file or a network). 
In the above definition, 'AddressFilter' allows only the Location attribute from the 
Address to pass through. 
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For the BusinessAddtess and Residential^didress Filter Objects, the syntax is: 

. filter BusinessAddressFiltef. inherits Ad 
filters BusinessAddress { 
,5 FaxNuinber/-; MobileNu^ . 

filter ResidentialAddressFiiter inherits AddressFilter 
. filters Resident ialAddress.v { 

DoorNumber;, " . 'v^ 

10 -■.};• ' ■ - ' • . . " \. • . ■ . ■ " ■ ■' ■ 

A Filter can inherit from other filters^^ 
consistent with the object hierarchy. In the above example (Fig,4) , BusinessAddress 148 
inherits from Address 147, and, in Fig. 6, so does Business AddressFilter 184 from 
15 AddressFilter 182. By inheriting from AddressFilter, BusinessAddressFilter acquires all 
the properites of AddressFilter. This means^^ t^ allows 
FaxNumber, MobileNumber and also the Location (acquired from AddressFilter) 
attributes to pass throu^ to the stream^- same applies for the 

ResidentialAddressFiiter Object 186. 



20 



The syntax for the GustbinerFilter Object 180 is; 



filter CustomeirFilter filters^C^ 
Name, Type, -Subtype; 
25 . AddressFilter filters Addres^^^^ 

select BusinessAddressFilter when Bii sines isAddr ess; 
select ResidentialAddressFiiter when; 

select default when, unknown; // catch all, 

30 . : ■};" - \.- . 

At the SO level, the FindGustomerFilter in Object 1^ 

filter FindCustomerFilter_In. .fSM FindCustomer { 
35 SearchPattern; 
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This syntax defines a Filter for FindCustbmer vMch would be used when the 
Service Object is sent from the^client to the server. -It.will only allow the 'SearchPattem' 
to pass through to the server. 

filter FindCust:omerFilter_Out filters FindCustomer{ 
association resultset .{ \ 
Name; 

This syntax defines a filter which would be used when the SO is sent to the client 
from the server. It would seiid back only the CustomerName attribute for the selected list 
of customers. 

A Filter can use other filters. This is similar to a relationship between them. In 
the above example, we can see that GustomerFilter (that filters the Customer object) 
makes use of AddressFilter to filter the Address relationship defined in the Customer 
object It also refines the selection capability if the relationship can contain instances of 
different types. For example, of a customer has both a residential address and a business 
address then both types of objects may be found in the relationship. The syntax specifies 
what filter has to be used arid when. If the type of an object in the relationship is 
unknown, then a select-default-when-imknown clause is used to default to externalize all 
the attributes in the unknown-object. 

In step 162 of Fig. 5/a schema compiler generates the set of Filters based on the 
syntax models noted above. Tlie syntax could equa^ 

(iii) Translation Schemas / 

The steps in Fig' 5 described up to this point occur for both client and server. 
The definition of the BOs and SOs occurs in the reispeietive Application layers 102, 108, 
and the definition of the Filters occurs in the respective mapper subsystems 1 16, 142. 
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On the server-side, a translational interface with the relational database is 
provided by the Common Data Services (Db Views) system 109. The CDS system 109 
has the knowledge necessary to act upon the executing reinstantiated Business Object to 
persist, retrieve and lock data: This means that neither the client nor the server (and the 
SOs and BOs) need to carry information relating to actual database activities. This is 
advantageous because different forms of database can be transparently accommodated 
(e.g. DB2 replaced by Oracle). 

Referring again to Fig. 5, step 164 iii the build-time sequence limits the 
succeeding steps only to servers (i.e. the CDS system 109 translation fimction). In step 
166, the DbView schemas are defined to translate from Business Objects into a relational 
representation. A schema compiler then operates in step 168 to generate DbView objects. 
Finally, SqlCode is written in step 170 that facilitates DB access. 

Fig. 7 shows an object model for the DiB translation. The reinstantiated 
Customer Object 146 (having the same one-to-n associations with Address Objects 147), 
is associated widi a Customei-ToDbViewTranslator Object 194. The Translator Object 
194 has attributes 'CustomerName', *CiistomerType', 'CustomerSubtype', 
*AddressCityName', and 'AddressLocation'. These attributes are of the respective type 
as shown in Fig. 7. The Translator Object 194 i also has an association with a 
CustomerDbView Object 196. This object carries the Sql knowledge with it relating to 
the attribute types in the Translator Object 194. 

The syntax for the Translator Object 194 is: 

translation CustoinerToDbViewTranslator { . 
Customer : CustomerDbView 
CustomerName: SqlName, 
CustomerType: SqlType/ 
CustomerSubtype: SqlSubtype 

association;';.^ 

Address : CustomerDbView, 
CityNamerSqlCityName, ' , 
Location : SqlLocation 



u 
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The syntax for the CustbmerDB Vie w Ob^ 

5 object CustomerDbView { . . 

StringSqlNamev SqlType, . .. SqlSubtype, S'qlCityName, 

. SqlLocation; ; ' 

. ■ } ' ■ ■'■' '-:■■:/■■ ■ ■■ ' . ' ■ ' .. ■. 

10 A translation is a specificatioio for mapping from one object to another. In the 

above example, the Customer Object 146 and its address relationship is mapped into the 
CustomerDbView Object 196. This construct abstracts the transformation from object 
domain to a relational domain, and also provides a uniform object interface. 

15 Execution o/a Service 



Fig. 8 shows the steps performed on a server in. response to a run-time service 
1:^: request, being 'FindCustomer'. In step 200, the BusinessAddress Object 148 is 

instantiated This Object is then populated, in step 202, with the fields previously 
20 described in Fig, 4. Similar steps (not shown) are performed for the Residential Address 
| y Object 149. The Customer Object 146 is now instantiated and is populated with the 

''Z fields: Name, Type and Subtyjjc in steps 204 and 206. The Customer Object is then 

associated with the related BtisinessAddress Object in step 208. In step 210, the 
FindCustomer SO 145 is instantiated. This forms a Service Object (termed -Parent') in 
25 step 212. In step 214, the FindCustomer Object is executed by making a call upon itself 
'All of these steps are performed in the service subsystem 112. 

A Filter Object *CustoinerFilter' is instantiated, which acts to convert 
Object into a binary stream, in step 216. In step 218, the Service (Parent) Object and 
30 Related Business Object, are associated. The CustbmerFilter Object is then deflated in 
step 220 to convert the Service Object and all associated Business Objects into a binary 
stream. Steps 216-220 are performed in the mapper subsystem 116. 



mnntofo 
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The binary streain. is; then routed to the -target server in step 222 (by the 
transaction subsystem 1 18); .. Fjhally, in step 224, the binary stream is sent by the comms 

subsystem 120 to the target server. 

". .. \ ' 

5 turning now to Fig: 9, the steps performed on the server are described; The 

binary stream from the client is received in step 230: the Logical Unit of Work (LUW) 
commitment is then controlled by the Transaction GoiitroUer 140 (step 232). In step 234, 
a filter infers from the binaiy Stream what Filter Object was used on the client to create 
the binary stream. The CustomeiFilter Object 180 is selected. Using this filter, step 238 

10 inflates/reinstantiates the binary; stream into an object hierarchy, to recover the Service 
Object. In step 240, the Cus;tomerObject is execiited: Steps 234 through 238 are 
performed in the mapper subsystem 142, while step 240 is performed in the Application 
layer 108 by the execute function 144. 

15 In this case, the required execution action vras "search" in which case the 

Customer Object is stored, in step 242, into a Customer Table 244. This transaction is 
handled by the CDC DbView system 109, in accordance with the translation schema 
described above. 

20 There then follows a test, in the application layer 108, as to whether any errors 

were encountered (step 246). If "Yes", details of the errors are associated with the 
FindCustomerObject in step 248: FoUovwng on, in step 250, a new CustomerFilter Object 
is created (step 250), and an jassociation of it performed with the existing Customer 
Object The same Service Object originally instantiated on the client is utilised on the 

25 server to return to service result. The associated Business Objects will be a modified 
form of the original BO or a newly instantiate BO, depending upon the result of the 
database access. In step 254, the Service Object is deflated using the Filter into a binary 
stream. All of steps 248 through 254 are performed ih the mapper subsystem 142. 



30 The transaction subsystmi 140 then performs the work, in .steps 256 and 258, of 

commiting or aborting the Logical Unit of Work's transaction boundary, and sending the 
binary stream to the target client - ^^.^ 

No record of the Servide pbject and associated Service Object(s) are kept on the 
35 server after comniitment has occurred. 
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{ Fig. 10 shows the steps performed at the client when a binary stream is returned 

It is firstly received by the comms subsystem 120 (step 270). In step 272, the reply binary 
stream is inflated by the mapper subsystem 116 into an object hierarchy. In step 274, the 
5 application layerl02 deals with the result CustomerObject. Again, no record of the 
Service Object and associated Business Object(s) are kept on the client. 

Advantages 

10 For the present invehlipn^ interaction between the cUent and server occurs in a 

way that proves to be highly scalable from the server point of view. Objects exist on the 
server for the brief duration of transactions. Instead of niillidns of Objects^ that require 
memory and other computing resources to support thousands of clients, the mmiber of 
Objects existing on the server at one point of time is reduced by thousand folds, the 

15 Objects also exist only for the duration of the transaction. The invention further enhances 
scalability in that there is no sharing of BOs on the server by different clients, rather this 
is done only at database level. 

The use of filters in the Mapper subsysteni significantly reduces the amount of 
20 data sent across the network, and thus also eiihances the overall scalability and 
performance of the computirig applications that are supported. For example, to update a 
customer address, the custoirier unique id and the address object are ^r However, 
the Customer Objects may have many other attributes (name, age, sex, social security 
number, etc) and many other associated Objects (accounts, history, loans, etc). For each 
25 type of transaction, which Objects and wiiat attributes of these Objects are required to be 
transmitted is specified in a manner to create efficiencies. There also is an overall 
reduction in the number of remote calls by having the SO and BO(s) 'package' passed- 
by-value, 

30 Location transparency aiid load balancing is also a feature of the iiivention, since 

a client does not need to know where a service request is being executed, meaning that the 
target server can be chosen to suit load demands and availability. 
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The externalizatipri Service Object r(iand its associated Objects), in a 
flattened buffered form, is achieved by asyhchronous messaging. This . allows 
optimisation of server utilisation: : 

5 \ - The invention also offers the important advantage that service requests between 

client and server can be handled synchronously or asynchronously. 

The invention also is independent of the transport layer implementation, giving it 
great flexibility across a number of computing platforms and architectures. 

Numerous alterations and modifications; as would be apparent to one sti^^ 
the art, can be made without departing from the bsisic inventive concept. All such 
modifications and alterations are to be considered as ihcorporated herein. 




